feat: Add reason, variant to flagsmith eval output - #74

`eval` has only ever said what an SDK resolves, never why. A flag that is on
because of a segment override, an identity override or a percentage split all
looked identical, so answering "why is this on for that user" meant leaving the
terminal for the dashboard.

flagsmith-go-client#221 puts `Reason` and `Variant` on `Flag`, populated from
the engine in local evaluation and from the `reason` and `variant` fields of
`/flags` and `/identities` remotely. This surfaces both.

Both are `omitempty` rather than always present. The EvaluationResult schema
marks them required, but an SDK API that predates them reports neither, and no
variant applies to a standard feature or to an evaluation with no identity to
bucket. An empty string would read as a reason of its own, so absence is the
honest answer — the same treatment `segments` already gets, and what keeps
`--json` a subset rather than a fiction.

The table grows a column only where there is something to put in it, so an API
reporting neither renders exactly as it does today. `--js` is deliberately
untouched: a frontend SDK hydrates from enabled and value, and anything else is
state it would carry without ever reading.

go.mod pins a pseudo-version until #221 is merged and released.

beep boop

The eval reason/variant work was developed against an unreleased commit,
so go.mod pinned a pseudo-version. v5.2.0 is out; pin the release.

beep boop